home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0125 / 319.txt < prev    next >
Text File  |  1997-04-16  |  30KB  |  769 lines
  1. Info-Atari16 Digest         Thu,  6 Jun 91       Volume 91 : Issue 319
  2.  
  3. Today's Topics:
  4.                                Atari TT
  5.                          Autobooting Drive C
  6.                         Black Cauldron Wanted!
  7.                       Color monitor replacement?
  8.                         FSM-GDOS...When? How?
  9.            GIF decompressor in GFA Basic 3.0 (not a viewer)
  10.                    Hard-drive on a 520ST? (2 msgs)
  11.                          Man w/ pipe (2 msgs)
  12.                      More than 4 Meg ?? (2 msgs)
  13.                   Neophyte question: what's Blitter?
  14.                            Re: Man w/ pipe
  15.                    XOR  (Was RE: More than 4 Meg?)
  16.  
  17. Welcome to the Info-Atari16 Digest.  The configuration for the automatic
  18. cross-posting to/from Usenet is getting closer, but still getting thrashed
  19. out.  Please send notifications about broken digests or bogus messages
  20. to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
  21.  
  22. Please send requests for un/subscription and other administrivia to
  23. Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
  24. instead of the moderators are likely to be lost or ignored.
  25.  
  26. If you want to unsubscribe, and you're receiving the digest indirectly
  27. from someplace (usually a BITNET host) that redistributes it, please
  28. contact the redistributor, not us.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: 5 Jun 91 09:57:34 GMT
  32. From: mcsun!hp4nl!star.cs.vu.nl!hvaalde@uunet.uu.net (Aalderen van Harold)
  33. Subject: Atari TT
  34. To: Info-Atari16@naucse.cse.nau.edu
  35.  
  36. apratt@atari.UUCP (Allan Pratt) writes:
  37.  
  38. >You can buy a 2MB ST RAM add-on card, for a total of 4MB of ST RAM.  There
  39. >may one day be an 8MB ST RAM add-on card, resulting in a total of 10MB
  40. >of ST RAM.
  41.  
  42. >You can buy a 4MB TT RAM add-on card.  It may be that, with some work, you
  43. >can make this address 16MB of TT RAM.  In future (now?) you can buy 16MB of
  44. >TT RAM from Atari -- I'm just not sure.
  45.  
  46. Since where on the subject now. Is there a legal way to find out
  47. the begin and end adresses of the ST-RAM and the same for TT_RAM
  48. And for the ROM?
  49.  
  50. I want to write a routine that as some 32 bit number as input and
  51. assuming that it is an address it determines if it is ROM, ST_RAM or TT_RAM
  52. or just JUNK and if it lies in the system part of RAM or in the TPA part.
  53.  
  54. any info appreciated?
  55.  
  56. Harold van Aalderen (hvaalde@cs.vu.nl)
  57.  
  58. ------------------------------
  59.  
  60. Date: 7 Jun 91 03:01:21 GMT
  61. From:
  62.  noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!spool.mu.edu!agate!darkstar!ucscb.UCS
  63.  C.EDU!rome@arizona.edu (60380000)
  64. Subject: Autobooting Drive C
  65. To: Info-Atari16@naucse.cse.nau.edu
  66.  
  67. I am borrowing my friend's Mega 2 for the summer and he has an SHS205 hard
  68. drive attatched.  When I got it, it would boot all of the stuff in the
  69. AUTO folder on the C partition (actually, that was the only thing that
  70. it would boot, it would not read a floppy at bootup!)  I seemed to have
  71. messed something up and now it will not boot off the hard drive, I have to
  72. boot off a floppy and with all of the utilities, it takes forever.  Does
  73. anyone know how I can fix the C partition to autoboot again???????
  74.  
  75. Thanks,
  76.    Roman Baker
  77.  
  78. ------------------------------
  79.  
  80. Date: 6 Jun 91 15:14:39 GMT
  81. From: aurs01!whitcomb@uunet.uu.net (Jonathan Whitcomb)
  82. Subject: Black Cauldron Wanted!
  83. To: Info-Atari16@naucse.cse.nau.edu
  84.  
  85. Does anyone have a copy of the game Black Cauldron that
  86. they wish to unload, or know where I can still purchase
  87. a copy?  I've just started re-reading the Prydain
  88. Chronicles by Lloyd Alexander, and thought it would be
  89. fun to play the game after reading the book.
  90.  
  91. Thanks!
  92. **********************************************************************
  93. Jonathan Whitcomb                    UUCP: <whitcomb%aurgate@mcnc.org>
  94. Alcatel Network Systems, Raleigh, NC                    Delphi: JBWHIT
  95.  
  96.  
  97. ------------------------------
  98.  
  99. Date: 6 Jun 91 17:28:35 GMT
  100. From: noao!asuvax!ncar!elroy.jpl.nasa.gov!wciu!abode!scale@arizona.edu (Luis
  101.  Outumuro)
  102. Subject: Color monitor replacement?
  103. To: Info-Atari16@naucse.cse.nau.edu
  104.  
  105.         Hi David,
  106.                 $230 is a very fair price for a brand new monitor!  By all
  107. means, get the new monitor.  Bye.............
  108.  
  109.                                         Luis
  110.  
  111. ------------------------------
  112.  
  113. Date: 6 Jun 91 20:03:36 GMT
  114. From: tempest.Berkeley.EDU!kawakami@ucbvax.berkeley.edu (John Kawakami)
  115. Subject: FSM-GDOS...When? How?
  116. To: Info-Atari16@naucse.cse.nau.edu
  117.  
  118. In article <1991May31.191105.13736@lonex.radc.af.mil> longj@lonex.radc.af.mil
  119.  (Jeffrey K. Long) writes:
  120. >Questions:
  121. >1) When will it be relesed ?
  122.  
  123. According to a letter from Goldleaf, there is less than two weeks before
  124. it is released.  Seems that Goldlead is just itching to send it out ASAP
  125. (after all, they have possibly the only FSM-ready program on the market,
  126. thus the new GDOS is a selling point.)
  127.  
  128.  
  129. >2) Who will handle distribution (Atari Directly, or through dealers, mail
  130. >   order, ...)?
  131.  
  132. Probably all channels.  I would hope that they distribute it in addition
  133. to the old GDOS (in software packages.)
  134.  
  135. >3) What will it cost, and will it include (as I have heard rumoured) drivers
  136. >   for most printers including the HP DeskJet (original version)?
  137.  
  138. Cost?  Beats me.  It's supposed to include a DJ driver, as well as an HP
  139. Laserjet driver and Epson drivers.  They'd be stupid to drop any drivers
  140. in the package.
  141.  
  142. >4) Can I get it now by buying Goldeaf's Wordflair II?
  143.  
  144. No.  They are going to charge cost plus shipping and handling when they
  145. sell FSM.
  146. >----------------------------------------------------------------------------
  147. >Capt Jeff Long                         Rome Laboratories, Griffiss AFB, NY
  148. >longj@lonex.radc.af.mil (preferred)    Network Design Laboratory
  149. >jlong@cassiopeia.radc.af.mil           (315)330-7751 or (DSN)587-7751
  150.  
  151.  
  152. John Kawakami                  kawakami@ocf.berkeley.edu
  153.                                ucbvax!ocf.berkeley.edu!kawakami
  154.  
  155. ------------------------------
  156.  
  157. Date: 6 Jun 91 23:31:06 GMT
  158. From:
  159.  noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio
  160.  -state.edu!linac!uwm.edu!spool.mu.edu!cs.umn.edu!uc!noc.MR.NET!ns!ns!logajan@ar
  161.  izona.edu (John Logajan)
  162. Subject: GIF decompressor in GFA Basic 3.0 (not a viewer)
  163. To: Info-Atari16@naucse.cse.nau.edu
  164.  
  165. REM  This GFA Basic 3.0 program unpacks the images in GIF files, creating RGB
  166. REM  color tables, and an uncompressed image array.  Each byte in the image
  167. REM  array points into the intensity values in the RGB color tables.  This means
  168. REM  the image can contain only 256 different colors, but those colors can be
  169. REM  selected from a palette of 16.7 million.
  170. REM
  171. REM  *THIS IS NOT A COMPLETE PROGRAM*  It does not display the GIF images.
  172. REM  I leave that up to you to figure out how to do.  Good luck.  By the way,
  173. REM  this is pretty slow.  It does run much faster if compiled.
  174. REM
  175. REM  Totally original code by John Logajan, June 6, 1991.  I don't know what
  176. REM  legal status it has, as CompuServe owns GIF, and I've heard rumors that
  177. REM  the owners of the LZW compression routines aren't happy with CompuServe.
  178. REM  If it was up to me, this code would be released into the public domain.
  179. REM
  180. INPUT "Filename: ",a$
  181. OPEN "I",#1,a$
  182. DIM pcl|(260),prep&(4097),scar|(4097),temp|(4097)
  183. pcp%=VARPTR(pcl|(0))
  184. sig$=""
  185. version$=""
  186. FOR j&=1 TO 3
  187.   sig$=sig$+CHR$(INP(#1))
  188. NEXT j&
  189. FOR j&=1 TO 3
  190.   version$=version$+CHR$(INP(#1))
  191. NEXT j&
  192. IF sig$="GIF"                               !  Check for GIF signature.
  193.   swidth&=INP(#1)+INP(#1)*256               !  Some sort of screen size
  194.   sheight&=INP(#1)+INP(#1)*256              !  neither of which I use.
  195.   tmp|=INP(#1)
  196.   global!=BTST(tmp|,7)                      ! Check for Global Color Map.
  197.   gpixel&=(tmp| AND 7)+1                    ! Global bits per pixel.
  198.   gcolres&=(SHR|(tmp|,4) AND 7)+1           ! Color range. I don't use.
  199.   gbackground&=INP(#1)                      ! Background color. I don't use.
  200.   tmp|=INP(#1)
  201.   IF global!                                  ! We have a Global Color Map.
  202.     crange&=SHL(1,gpixel&)                    ! Color range.
  203.     pixel&=gpixel&                            ! Bits per pixel.
  204.     DIM r|(crange&),g|(crange&),b|(crange&)   ! RGB color map reserved.
  205.     FOR j&=0 TO crange&-1                     ! Go gety the map RGB values.
  206.       r|(j&)=INP(#1)
  207.       g|(j&)=INP(#1)
  208.       b|(j&)=INP(#1)
  209.     NEXT j&
  210.   ENDIF
  211.   REPEAT                             ! Main Image(s) Loop
  212.     sep|=INP(#1)
  213.     IF sep|=&H21                     ! Throw away any Extension Blocks
  214.       tmp|=INP(#1)
  215.       DO
  216.         bc|=INP(#1)
  217.         EXIT IF bc|=0
  218.         FOR j&=1 TO bc|
  219.           tmp|=INP(#1)
  220.         NEXT j&
  221.       LOOP
  222.       sep|=INP(#1)
  223.     ENDIF
  224.     IF sep|=&H2C                            ! Look for Image Descriptor Start
  225.       offleft&=INP(#1)+INP(#1)*256          ! Some sort of offset, I don't use.
  226.       offtop&=INP(#1)+INP(#1)*256           ! I don't use.
  227.       width&=INP(#1)+INP(#1)*256            ! Image width (pixels)
  228.       height&=INP(#1)+INP(#1)*256           ! Image height (pixels)
  229.       imglen%=width&*height&                ! Total pixels in the image.
  230.       DIM pic|(imglen%+256)                 ! Reserve image space + spare room.
  231.       pici%=0
  232.       tmp|=INP(#1)
  233.       uselocal!=BTST(tmp|,7)                ! Look for Local Color Map
  234.       interlace!=BTST(tmp|,6)               ! See if image is interlaced.
  235.       lpixel&=(tmp| AND 7)+1                ! Local bits per pixel.
  236.       pass|=0
  237.       hline&=0
  238.       vcol&=0
  239.       lstep&=8
  240.       IF uselocal!                           ! We have a Local Color Map
  241.         crange&=SHL(1,lpixel&)               ! Color range
  242.         pixel&=lpixel&                       ! Bits per pixel
  243.         IF NOT global!
  244.           DIM r|(crange&),g|(crange&),b|(crange&) ! Reserve room for color map.
  245.         ENDIF
  246.         FOR j&=0 TO crange&-1                ! Go fill local color map.
  247.           r|(j&)=INP(#1)
  248.           g|(j&)=INP(#1)
  249.           b|(j&)=INP(#1)
  250.         NEXT j&
  251.       ENDIF
  252.       PRINT crange&;" colors."
  253.       PRINT width&;" * ";height&
  254.       REM
  255.       REM This is the LZW decompresser
  256.       REM
  257.       initcodesize&=INP(#1)              ! How many bits in first code.
  258.       clearcode&=SHL(1,initcodesize&)    ! Now we know the clear code.
  259.       eofcode&=clearcode&+1              ! Now we know the eof code.
  260.       firstfree&=clearcode&+2            ! Where to put first incoming code.
  261.       FOR j&=0 TO clearcode&-1           ! We put roots into string table.
  262.         REM Prep&() entries point to the previous character
  263.         prep&(j&)=5000                   ! Are roots so we make them too big.
  264.         REM scar|() entries are the actual string value at that point
  265.         scar|(j&)=j&
  266.       NEXT j&
  267.       INC initcodesize&
  268.       cbp&=0
  269.       cpt&=0
  270.       lpt&=0
  271.       GOSUB codeclear                    ! Let's get started.
  272.       REPEAT                             ! Do a whole compressed image.
  273.         GOSUB getcode                    ! Get a code.
  274.         IF code&=clearcode&              ! Always test it for clear code.
  275.           GOSUB codeclear
  276.         ELSE
  277.           IF code&<freecode&             ! We have this code.
  278.             GOSUB codeout                ! Expand it.
  279.             prep&(freecode&)=oldcode&    ! And save it as next code,
  280.             scar|(freecode&)=pscar|      !   appending current character.
  281.           ELSE                           ! We don't have this code.
  282.             prep&(freecode&)=oldcode&    ! So, save it,
  283.             scar|(freecode&)=pscar|      !   appending previous first character.
  284.             GOSUB codeout                ! Expand it.
  285.           ENDIF
  286.           INC freecode&                  ! Get ready for next.
  287.           oldcode&=code&                 ! Remember last code.
  288.           IF freecode&>=maxcode&         ! Look out for variable sized codes.
  289.             IF codesize&<12              ! Don't go over 12bit limit.
  290.               INC codesize&              ! Adjust code size up one bit.
  291.               maxcode&=SHL(1,codesize&)
  292.               readmask&=maxcode&-1
  293.             ENDIF
  294.           ENDIF
  295.         ENDIF
  296.       UNTIL code&=eofcode&               ! We're out'a here.
  297.       sep|=INP(#1)
  298.     ENDIF
  299.   UNTIL sep|=&H3B                     ! Look for GIF Terminator
  300.   REM
  301.   PRINT "Your code goes here."
  302.   REM
  303.   REM pic|() contains image, one byte per pixel -- pointing into RGB maps.
  304.   REM The image data in pic|() is left to right, top to bottom
  305.   REM i.e. The first 640 bytes of a 640 pixel wide image make up the first
  306.   REM      horizontal line, the next 640 bytes make up the second line...
  307.   REM width& = number of horizontal pixels (bytes)
  308.   REM height& = number of vertical pixels (bytes)
  309.   REM r|()   contains the red level values 0-255 intensities.
  310.   REM g|()   contains the green level values 0-255 intensities.
  311.   REM b|()   contains the blue level values 0-255 intensities.
  312.   REM crange& = the number of entries in each color map.
  313.   REM
  314.   REM Have fun.
  315.   REM
  316. ELSE
  317.   PRINT "Not a GIF file."
  318. ENDIF
  319. END
  320. PROCEDURE getcode
  321.   REM This routine extracts code bits out of a very long bit stream.
  322.   REM cpt&=current byte in the buffer block
  323.   REM cbp&=current start bit in the byte
  324.   REM codesize&=current code bit width
  325.   REM lpt&=last byte in the buffer block
  326.   sumb&=codesize&+cbp&
  327.   smo%=lpt&-cpt&
  328.   REM A 10 bit code can span 3 bytes, so there are many cases to handle.
  329.   IF sumb&<=8
  330.     IF smo%<1
  331.       GOSUB getblock
  332.     ENDIF
  333.     code&=SHR&(pcl|(cpt&),cbp&) AND readmask&
  334.     IF sumb&=8
  335.       INC cpt&
  336.       cbp&=0
  337.     ELSE
  338.       cbp&=sumb&
  339.     ENDIF
  340.   ELSE
  341.     IF sumb&<=16
  342.       IF smo%<2
  343.         GOSUB getblock
  344.       ENDIF
  345.       code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&) AND readmask&
  346.       IF sumb&=16
  347.         ADD cpt&,2
  348.         cbp&=0
  349.       ELSE
  350.         INC cpt&
  351.         cbp&=sumb&-8
  352.       ENDIF
  353.     ELSE
  354.       IF smo%<3
  355.         GOSUB getblock
  356.       ENDIF
  357.       code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&) OR
  358.  SHL&(pcl|(cpt&+2),16-cbp&) AND readmask&
  359.       REM
  360.       REM Just in case that line gets truncated in transit, here it is:
  361.       REM code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&)
  362.       REM              OR SHL&(pcl|(cpt&+2),16-cbp&) AND readmask&
  363.       REM
  364.       ADD cpt&,2
  365.       cbp&=sumb&-16
  366.     ENDIF
  367.   ENDIF
  368. RETURN
  369. PROCEDURE getblock
  370.   REM The image date is broken up in blocks less than 256 bytes long in the
  371.   REM GIF file.  I get one of those blocks whenever I am running short.
  372.   smo2&=0
  373.   WHILE cpt&<>lpt&              ! Move any as yet unused bytes from previous
  374.     pcl|(smo2&)=pcl|(cpt&)      !   block up to front.
  375.     INC smo2&
  376.     INC cpt&
  377.   WEND
  378.   cpt&=0
  379.   bc|=INP(#1)
  380.   lpt&=bc|+smo%
  381.   IF bc|<>0                     ! And then stick the new block on behind.
  382.     BGET #1,pcp%+smo%,bc|
  383.   ENDIF
  384. RETURN
  385. PROCEDURE codeclear
  386.   REM This clears the code table.  It does this right away, and every 4096
  387.   REM   codes sent thereafter -- and sometimes sooner.
  388.   freecode&=firstfree&
  389.   codesize&=initcodesize&
  390.   maxcode&=SHL(1,codesize&)
  391.   readmask&=maxcode&-1
  392.   REPEAT
  393.     GOSUB getcode
  394.   UNTIL code&<>clearcode&
  395.   GOSUB codeout                  ! We always send the first code out right
  396.   oldcode&=code&                 !   away after a code clear.
  397. RETURN
  398. PROCEDURE codeout
  399.   REM  This routine expands the code into real image data.
  400.   oz&=-1
  401.   ooz&=code&
  402.   REPEAT                         ! I have to extract the string backwards
  403.     INC oz&
  404.     temp|(oz&)=scar|(ooz&)
  405.     ooz&=prep&(ooz&)
  406.   UNTIL ooz&=5000
  407.   pscar|=temp|(oz&)
  408.   IF interlace!                  ! A nitwit interlaced image.  Bleech.
  409.     FOR ooz&=oz& TO 0 STEP -1    ! Take the backward string and put it into
  410.       IF vcol&=width&            !  the picture image, forwards.
  411.         vcol&=0
  412.         hline&=hline&+lstep&     ! Set up the crazy interlace cases.
  413.         IF hline&>=height&
  414.           INC pass|
  415.           IF pass|=1
  416.             lstep&=8
  417.             hline&=4
  418.           ENDIF
  419.           IF pass|=2
  420.             lstep&=4
  421.             hline&=2
  422.           ENDIF
  423.           IF pass|=3
  424.             lstep&=2
  425.             hline&=1
  426.           ENDIF
  427.           IF pass|=4
  428.             hline&=height&
  429.           ENDIF
  430.         ENDIF
  431.         pici%=hline&*width&          ! I've figured out where it goes.
  432.       ENDIF
  433.       pic|(pici%)=g|(temp|(ooz&))    ! Now I finally put it there.
  434.       INC pici%
  435.       INC vcol&
  436.     NEXT ooz&
  437.   ELSE                                ! Ah, a seqential image.
  438.     FOR ooz&=oz& TO 0 STEP -1         ! Take the backward string and put it
  439.       pic|(pici%)=g|(temp|(ooz&))     ! into the picture image, forwards.
  440.       INC pici%
  441.     NEXT ooz&
  442.   ENDIF
  443. RETURN
  444. --
  445. - John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428
  446. - logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
  447.  
  448. ------------------------------
  449.  
  450. Date: 6 Jun 91 16:47:15 GMT
  451. From:
  452.  noao!asuvax!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!g
  453.  ecrdvm1!syspmzt@arizona.edu
  454. Subject: Hard-drive on a 520ST?
  455. To: Info-Atari16@naucse.cse.nau.edu
  456.  
  457. In article <1991Jun5.181758.4095@murdoch.acc.Virginia.EDU>,
  458. lch3e@holmes.acc.Virginia.EDU (Lauren C. Howard) says:
  459. >
  460. >Can a hard-drive (spec. Megafile 30) be used with a stock 520ST?
  461. >Will there be enough memory left to run WordPerfect? Timeworks DTP?
  462. >
  463. >Why are the Megafile 30's being sold off so cheap right now?  I know
  464. >they're discontinued; but is there anything wrong with them?  Are
  465. >they upgradeable?
  466. >
  467. I can't answer most of the questions, but having been in the market for
  468. a hard drive recently, I can tell you that every dealer I've talked to
  469. about the Megafile 30 has had the same response: "They're really slow.
  470. Most of my customers can't deal with anything this slow."
  471.  
  472. Mind that they're dealers with non-Atari drives to sell, but it became
  473. the expected response whenever I talked to one of them.  I found a
  474. 49M 28ns drive from Carter Graphics for $414 that I'm waiting for now.
  475. Atari's Megafile was $365 at most places that would touch them.  Seemed
  476. like a simple choice to me.
  477.  
  478. Phil Z
  479.  
  480. ------------------------------
  481.  
  482. Date: 6 Jun 91 17:55:07 GMT
  483. From: noao!asuvax!ncar!elroy.jpl.nasa.gov!wciu!abode!scale@arizona.edu (Luis
  484.  Outumuro)
  485. Subject: Hard-drive on a 520ST?
  486. To: Info-Atari16@naucse.cse.nau.edu
  487.  
  488.         Hi Lauren,
  489.                 Yes, a hard drive such as the Megafile 30 can be used with a
  490. "stock" 520ST, although I doubt there would be enough memory left to run
  491. either WordPerfect or Publisher ST.  You could however run the likes of
  492. WordWriter and Publishing Partner.  Having a hard drive connected to a 512k ST
  493. really restricts which programs you can use; this would be an excellent time to
  494. upgrade your computer.
  495.         Megafiles are so cheap now, because hard drive prices are at an
  496. all-time low; and this is industry wide (not just Atari).  There is nothing
  497. wrong with the Megafile 30's; low OEM prices of the mechanism and market
  498. competition allow the price to be low.  Yes, the Megafile 30's are upgradeable;
  499. one of the most popular replacement mechanisms for the Megafile 30 is the
  500. Mitsubishi MR535.  The MR535 (when connected to a RLL controller, like the
  501. Megafile 30 has) is a 65m, 25ms hard drive; it simply plugs and mounts in the
  502. same place as the Megafile 30's Seagate ST238R mechanism, although you will
  503. need different software to format and partition the drive with (such as Supra's
  504. Hard Drive Utilities, Diamond Cache would be nice too).  I hope this helps,
  505. take care.  Bye................
  506.  
  507.                                         Luis
  508.  
  509. ------------------------------
  510.  
  511. Date: 6 Jun 91 18:54:48 GMT
  512. From: noao!ncar!gatech!prism!mailer.cc.fsu.edu!nu!boyd@arizona.edu (Mickey Boyd)
  513. Subject: Man w/ pipe
  514. To: Info-Atari16@naucse.cse.nau.edu
  515.  
  516. In article <1991Jun6.131017.12110@ira.uka.de>, S_DINGLER@iravcl.ira.uka.de (|S|
  517.  Florian Dingler) writes:
  518. >Hi folks!
  519. >
  520. >I wonder if anyone knows who the man smoking a pipe is. You know, the one you
  521. >find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little
  522. >joke or a special person or what ?
  523. >Please write followups, no mail.
  524.  
  525. Bob, from the Church of the Subgenius.  Consult your weirdest bookstore for
  526. details.
  527.  
  528. --
  529.     ---------------------------------+-------------------------------------
  530.              Mickey R. Boyd          |  "Kirk to Enterprise.  All clear
  531.           FSU Computer Science       |      down here.  Beam down
  532.         Technical Support Group      |      yeoman Rand and a six-pack . ."
  533.       email:  boyd@fsucs.cs.fsu.edu  |
  534.     ---------------------------------+-------------------------------------
  535.  
  536. ------------------------------
  537.  
  538. Date: 6 Jun 91 21:16:57 GMT
  539. From:
  540.  noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!news-server.
  541.  csri.toronto.edu!utgpu!watserv1!roulston@arizona.edu (James Parker)
  542. Subject: Man w/ pipe
  543. To: Info-Atari16@naucse.cse.nau.edu
  544.  
  545. In article <1991Jun6.161545.14157@rice.edu> bemo@spacsun.rice.edu (Brian D.
  546.  Moore) writes:
  547. >In article <1991Jun6.131017.12110@ira.uka.de>, S_DINGLER@iravcl.ira.uka.de (|S|
  548.  Florian Dingler) writes:
  549. >|> Hi folks!
  550. >|>
  551. >|> I wonder if anyone knows who the man smoking a pipe is. You know, the one
  552.  you
  553. >|> find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little
  554. >|> joke or a special person or what ?
  555. >|> Please write followups, no mail.
  556. >
  557. >     Hey buddy, that's Bob Dobbs, leader of the Church of the Sub-Genius.
  558. >Slack off! Quit your job!  Send your money to Bob!!
  559. >
  560.  
  561. So, how do get a look at the Atari character set anyway?
  562.  
  563. Please send em the necessary slack.
  564.  
  565. thanx
  566. james
  567.  
  568. ------------------------------
  569.  
  570. Date: 7 Jun 91 00:42:15 GMT
  571. From:
  572.  noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!pacbell.com!iggy.GW.Vitalink.COM!lll-
  573.  winken!taco!taco.cc!twmanino@arizona.edu (TONY W MANINO)
  574. Subject: More than 4 Meg ??
  575. To: Info-Atari16@naucse.cse.nau.edu
  576.  
  577. >>Nope. TOS 1.6 has a screwed up memory sizer that assumes that if two banks of
  578. >>RAM exist then both banks are the same size. I don't know if this is a bug
  579. >>in the true sense or malicious crippling but it is sad.
  580. >>
  581. >>BTW, a bank is two SIMMs since memory access is on a word basis.
  582. >>
  583. >>      512K    = 2 x 256K SIMMs
  584. >>      1Mb     = 4 x 256K SIMMs
  585. >>      2Mb     = 2 x 1Mb SIMMs
  586. >>      2.5Mb   = 2 x 1Mb SIMMs + 2 x 256K SIMMs (Not with TOS 1.6)
  587. >                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  588. >I heard this works on TOS 1.6 if you put the 256k SIMMs as the first bank
  589. >and the 1M SIMMs as the second bank.  But I could be wrong.  If you're
  590. >having trouble, though, it's trivial to try it the other way.
  591. >>      4Mb     = 4 x 1Mb SIMMs
  592.  
  593. There's a file at atari.archive that fixes the 2.5 meg problem... It's called
  594. SIMMFIX.
  595.  
  596. You put it in your auto folder.  It reprograms the MMU, then does a warmstart.
  597.  
  598. I get 2 bombs on the first boot attempt, but when the machine resets, it does
  599. just fine.  Any subsequent warmstarts just boot right up.
  600.  
  601. Be sure to read the instructions....
  602.  
  603.  
  604. Hope this helps,
  605. Tony
  606. twmanino@eos.ncsu.edu
  607.  
  608. ------------------------------
  609.  
  610. Date: 6 Jun 91 15:16:54 GMT
  611. From: mcsun!ukc!mucs!els!camm@uunet.uu.net (Ian Camm)
  612. Subject: More than 4 Meg ??
  613. To: Info-Atari16@naucse.cse.nau.edu
  614.  
  615. In article <1991Jun5.222630.24777@jato.jpl.nasa.gov> vsnyder@jato.Jpl.Nasa.Gov
  616.  (Van Snyder) writes:
  617. >In article <3153@odin.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes:
  618. >>In article <1991Jun4.112631.10649@cs.nott.ac.uk> dpg@cs.nott.ac.uk
  619. >>(Dave Gymer) writes:
  620. >>> ... I believe, that the MMU in the STe can
  621. >>>only handle .25 and 1 meg SIPPS/SIMMS, and these are arranged in two banks,
  622. >>>which must contain the same amount (hence, memory configurations can only
  623. >>>be .5 meg, 1 meg, 2 meg, 2.5 meg, and 4 meg). I too have a four meg STe.
  624. >>                          ~~~~~~~
  625. >>
  626. >>Nope. TOS 1.6 has a screwed up memory sizer that assumes that if two banks of
  627. >>RAM exist then both banks are the same size. I don't know if this is a bug
  628. >>in the true sense or malicious crippling but it is sad.
  629. >>
  630. >>BTW, a bank is two SIMMs since memory access is on a word basis.
  631. >>
  632. >>      512K    = 2 x 256K SIMMs
  633. >>      1Mb     = 4 x 256K SIMMs
  634. >>      2Mb     = 2 x 1Mb SIMMs
  635. >>      2.5Mb   = 2 x 1Mb SIMMs + 2 x 256K SIMMs (Not with TOS 1.6)
  636. >                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  637. >I heard this works on TOS 1.6 if you put the 256k SIMMs as the first bank
  638. >and the 1M SIMMs as the second bank.  But I could be wrong.  If you're
  639. >having trouble, though, it's trivial to try it the other way.
  640. >>      4Mb     = 4 x 1Mb SIMMs
  641.  
  642.         Well 2.5Mb does work on my 520STE with TOS 1.6, but it does think there
  643. are 4Mb there. I have not had any problems yet but I have not (knowingly)
  644. tried to use all of the memory thus far. I have the feeling that when I
  645. do I will commit mass bit murder :-) by trying to throw them into spaces that
  646. aren't there. I will try changing the boards round and let you know what
  647. happens.
  648.  
  649. n
  650. e
  651. w
  652. s
  653.  
  654. f
  655. o
  656. d
  657. d
  658. e
  659. r
  660.  
  661. Cheers,
  662.  
  663. Ian
  664.  
  665. --
  666. Ian Camm                           | JANET: camm@uk.ac.man.ee.els
  667. Dept. of Electrical Engineering    | ARPA:  camm@els.ee.man.ac.uk
  668. University of Manchester, England  | UUCP:  ...!!ukc!man.ee.els!camm
  669. Disclaimer: If you think I need one make it up yourself.
  670.  
  671. ------------------------------
  672.  
  673. Date: 6 Jun 91 22:40:23 GMT
  674. From:
  675.  noao!ncar!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!aunro!ersys
  676.  !mforget@arizona.edu (Michel Forget)
  677. Subject: Neophyte question: what's Blitter?
  678. To: Info-Atari16@naucse.cse.nau.edu
  679.  
  680. darkstar@milton.u.washington.edu (Alden Hackmann) writes:
  681.  
  682. > We are the very new (3 days) owners of an Atari 1040 STe.
  683. > There is a toggle on the options menu for something called Blitter.
  684. > The little manual has no reference to it at all.  Can anyone enlighten
  685. > us as to the meaning of this option?
  686. >
  687. If you can select the "Blitter" option, do so.  It is a special graphic
  688. chip inside the machine that allows it to do Hardware Scrolling.  It
  689. makes for faster, smoother scrolling.  I'm not sure about the other
  690. capabilities.  It is better than the standard, though, so use it if you
  691. can.
  692.  
  693.  
  694. <<  ----------------------------------  >>
  695. <<  ersys!mforget@nro.cs.athabascau.ca  >>
  696. <<     mforget@ersys.edmonton.ab.ca     >>
  697. <<            Michel Forget             >>
  698. <<  ----------------------------------  >>
  699.  
  700. ------------------------------
  701.  
  702. Date: 6 Jun 91 20:39:54 GMT
  703. From:
  704.  noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!gecrdvm1
  705.  !syspmzt@arizona.edu
  706. Subject: Re: Man w/ pipe
  707. To: Info-Atari16@naucse.cse.nau.edu
  708.  
  709. In article <A1663047366@thelake.mn.org>, steve@thelake.mn.org (Steve Yelvington)
  710. says:
  711. >
  712. >[In article <1991Jun6.131017.12110@ira.uka.de>,
  713. >     S_DINGLER@iravcl.ira.uka.de (|S| Florian Dingler) writes ... ]
  714. >
  715. >> I wonder if anyone knows who the man smoking a pipe is. You know, the one
  716. >you
  717. >> find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little
  718. >> joke or a special person or what ?
  719. >> Please write followups, no mail.
  720. >
  721. >Bob is indeed a special person, being the revered icon of the Church of the
  722. >Sub-Genius.
  723. >
  724.  
  725. Well, now I know why Bob is seen on the dialog box of the ram disk I use.
  726. I'd thought that the programmer was really cool to spend the time drawing
  727. Bob.  Now I know that the real cool person is or was hidden inside Atari
  728. while they were developing the machine.
  729.  
  730. For all the deficiencies of the operating system, at least it offers
  731. slack to all who seek.
  732.  
  733. Phil Z
  734.  
  735. ------------------------------
  736.  
  737. Date: 6 Jun 91 18:56:50 GMT
  738. From:
  739.  noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!gecrdvm1
  740.  !syspmzt@arizona.edu
  741. Subject: XOR  (Was RE: More than 4 Meg?)
  742. To: Info-Atari16@naucse.cse.nau.edu
  743.  
  744. I can't reply to Ralph Berg, who asked about programming for the Cazio CZ1
  745. with XOR:
  746.  
  747. XOR is a generic patch editor that runs in Dr. T's KCS Multi-Programming
  748. Environment (MPE).  It can also be run as a standalone program.  As I
  749. understand it, XOR uses modules that describes the programming requirements
  750. for a given synth, and then uses a generalized interface to allow that
  751. programming.  Feedback from the synth category was very favorable to XOR
  752. over other available packages. I like the idea of going to XOR since it        s
  753. supports a lot of synths, some of which are not exactly popular models.        .
  754.  
  755. If you're not familiar with Dr. T's, they write a lot of midi software that
  756. may not always have the greatest flexibility right off the bat, but are well
  757. supported in upgrades, and are reasonably priced.  I've stayed with the KCS
  758. through 4 upgrades now, and with Tiger and Level II, have an extremely
  759. powerful sequencer environment that supports the functioning of many external
  760. programs; last night I figured how to initiate other GEM programs from
  761. within the KCS so that I don't have to reload my sequencer configuration
  762. just to get to my all-important Daleks game...
  763.  
  764. Phil Z
  765.  
  766. ------------------------------
  767.  
  768. End of Info-Atari16 Digest
  769. ******************************